\chapter{Projekt - architektura aplikacji}
\label{cha:architektura}
Wybór odpowiedniej architektury dla tworzonego systemu stanowi poważne wyzwanie
szczególnie w przypadku dużych aplikacji internetowych wykorzystujących najnowsze
możliwości technologiczne. Ma bowiem istotny wpływ m.in. na łatwość pielęgnacji, czyli
utrzymywalność (ang. maintainablility) systemu czy jego skalowalność (ang.
scalability)\cite{archMadeyski}.

\section{MVC}

Źródła MVC (Model-View-Controller) sięgają końca lat siedemdziesiątych i języka
Smalltalk-80. Paradygmat MVC stał się centralną koncepcją realizacji interfejsów
użytkownika w tym języku, jak również w innych językach i systemach zorientowanych
obiektowo. Jest również znakomitą ilustracją zasady podziału
odpowiedzialności (ang. separation of concerns). Zasada ta znajduje odzwierciedlenie
w~podziale klas aplikacji na trzy grupy: model (ang. model), widok (ang. view) i
kontroler (ang. controller), co obrazuje Rys. \ref{fig:mvc}. 
\begin{figure}[ht!]
\begin{center}
\includegraphics[scale=1.0]{mvc}
\caption{Model MVC}
\label{fig:mvc}
\end{center}
\end{figure}

Semantyka triady MVC i reguły komunikacji pomiędzy jej poszczególnymi elementami
są następujące.
Model związany jest z domeną aplikacji, zawiera jej elementy statyczne i behawioralne.
Najważniejszą składową modelu jest logika aplikacji oraz stojąca za nią logika
biznesowa. Innymi słowy, model określa działanie aplikacji oraz przetwarzane dane.
Powinien być tak zaprojektowany, żeby był niezależny od wybranego rodzaju prezentacji
oraz systemu obsługi akcji użytkownika (model nic nie wie o widoku i kontrolerze).
Jedyne powiązanie wychodzące z modelu to powiadomienie widoku o aktualnych
zmianach (change notification). W większości implementacji jest to rozwiązane za
pomocą systemu komunikatów lub z zastosowaniem wzorca
Observer.
\\\\
Widok zarządza graficzną lub tekstową prezentacją modelu (jest jego wizualnym
odwzorowaniem). Realizacja widoku jest już powiązana z konkretnym modelem.
Prezentacja nie może zostać wygenerowana bez znajomości specyfiki danych czy
operacji, które obrazuje użytkownikowi. Rys. \ref{fig:mvc} ilustruje to
powiązanie:
widok pobiera informacje z modelu (state query) ilekroć zostaje powiadomiony o jego zmianie.
Z drugiej strony model nie jest związany ze sposobem jego prezentacji. W związku
z~tym zmiany widoku nie pociągają za sobą zmian w modelu.
Kontroler jest natomiast odpowiedzialny za reagowanie na akcje użytkownika
(np. kliknięcia myszką), odwzorowując je na operacje zawarte w modelu (state change)
oraz na zmiany widoku (view selection). W połączeniu z widokiem odpowiada za dwa
aspekty interfejsu użytkownika (look and feel). 
odwołania do niej.
Wartość szkieletu architektonicznego MVC leży w dwóch podstawowych zasadach.
Pierwsza to separacja prezentacji i modelu, umożliwiająca zmianę interfejsu
użytkownika (np. udostępnienie usług aplikacji poprzez interfejs graficzny i tekstowy).
Druga zasada to separacja widoku i kontrolera. Klasycznym przykładem jest użycie 
dwóch kontrolerów związanych z jednym widokiem, które umożliwiają edycję widoku
lub jej nie umożliwiają \cite{archMadeyski}.


\section{Diagram warstw}
Rozdzielenie aplikacji na warstwy pozwala na luźne
łączenie(ang. loose-coupling) komponentów oraz na przejrzystość w działaniu
systemu.
Diagram przedstawiony na Rys. \ref{fig:warstwy} ukazuje zastosowaną warstową
architekturę Systemu Rozstrzygania Konkursów Internetowych.

\begin{figure}[ht!]
\includegraphics[scale=0.6]{warstwy}
\caption{Warstwy aplikacji}
\label{fig:warstwy}
\end{figure}

\section{Diagram komunikacji}
Aplikacja komunikuje się głównie za pośrednictwem protokołu http. Wyjątkiem
jest połączenie do bazy danych przez konektor jdbc. Zarówno
żądania jak i odpowiedzi http są przekazywane w formacie JSON. 
Diagram przedstawiony na Rys. \ref{fig:komunikacja} ukazuje system
komunikacji zastosowany w aplikacji.

\begin{figure}[ht!]
\includegraphics[scale=0.6]{komunikacja} 
\caption{Diagram komunikacji} 
\label{fig:komunikacja}
\end{figure}


%jak zabraknie stron to to sie doda
\section{Aplikacja w chmurze}
Bardzo interesującym rozwinięciem aplikacji byłoby umieszczenie jej w
chmurze. Pozwoli to m.in. na spory wzrost wydajności aplikacji, co może być
kluczowe przy konkursach z dużą liczbą partycypantów.\\\\
Usługi w modelu cloud computing nie wprowadzają nowych technologii, a raczej
zmieniają sposób wykorzystania już istniejących. Najbardziej oczywistą
korzyścią, jaką wnoszą, jest możliwość skorzystania z elementów infrastruktury
klasy enterprise po kosztach bezpośrednio odzwierciedlających wartość ich
możliwości operacyjnych. Dla małego biznesu, który potrzebuje niewielu serwerów
i~stosunkowo niewielkiej pamięci masowej dla swoich aplikacji, usługa w~chmurze
oferuje zazwyczaj coś znacznie tańszego niż jakakolwiek opcja ''on-premise'' nawet w dłuższym okresie. Niewielkie obciążenia nie zapewniają pełnego wykorzystania sprzętu i oprogramowania, w które trzeba zainwestować przy wdrożeniach własnych.
\\\\
Sukces chmur publicznych zachęca wiele organizacji do skorzystania z tej
techniki dostarczania usług i coraz więcej firm decyduje się na wdrażanie
projektów cloud services. Uruchomienie usług w~chmurze (prywatnej lub
publicznej) może zapewnić zarówno nowy strumień zysków, jak i wygodną
samoobsługę dla klientów firmy, przy minimalnych nakładach na rozszerzenie
istniejącej infrastruktury. 
Zdefiniowanie problemów, które mają rozwiązywać potencjalne cloud services to
pierwszy krok w~określaniu korzyści, jakie przedsięwzięcie to może wnieść do biznesu. Trzeba pamiętać, że w niektórych przypadkach konieczne może być przeniesienie całych aplikacji, w innych potrzebne będzie tylko kilka prostych usług (eksponowanych np. przez protokół web services).
\\\\
Po ustaleniu celu i rodzaju zastosowania cloud services, trzeba określić, jak
zostaną wykorzystane i ile to będzie kosztować. Koszty migracji zależą od stanu istniejących aplikacji, ich architektury oraz zakresu prac niezbędnych do wykonania, aby udostępnić ich funkcjonalności w~chmurze.
\\\\
Ocena kosztów w dużej mierze zależy od aplikacji i usług, które zamierza się
udostępniać w~chmurze. Do podstawowych składowych takiej oceny można zaliczyć:
ocenę stanu istniejących aplikacji, ocenę istniejących projektów interfejsu użytkownika, ocenę istniejącego projektu bezpieczeństwa, określenie, jak ma być zaimplementowane rozliczanie użytkowania, oszacowanie zakresu zmian w podstawowych aplikacjach oraz dodatkowych zadań związanych z ich przeprojektowaniem\cite{chmuraMuszynski}.

\section{Bezpieczeństwo aplikacji}

Każda aplikacja internetowa narażona jest na szereg ataków ze strony
szkodliwych użytkowników. Wraz z rozwojem internetu powstają kolejne techniki
służące atakowaniu serwisów www. System Rozstrzygania Konkursów Internetowych
posiada implementację technik sprzyjających ochronie aplikacji.

\subsection{Popularne ataki}
\begin{itemize}
  \item SQL Injection
  \item XSS
  \item DDoS
\end{itemize}

\subsection{Obrona przed atakami}

\subsubsection{SQL Injection}
Atak SQL Injection polega na wstrzyknięciu zapytania SQL przez pole formularza
i wykonanie go po stronie serwera na bazie danych. Taki atak może pobrać poufne
dane, podszyć się pod inną osobę lub zmodyfikować bazę\cite{sqlInj}.
Przykładowe wejście może wyglądać w sposób przedstawiony na listingu
\ref{lst:atakSqlInj}.
\begin{lstlisting}[caption={Atak SQL
Injection},numbers={none},label={lst:atakSqlInj}]
select * from user where username='admin' OR '1'='1' and password=' '
\end{lstlisting}
 
Takie zapytanie zezwala atakującemu na zalogowanie się do strony bez
dostarczania hasła, ponieważ wyrażenie OR jest zawsze prawdziwe\cite{sqlInjPrevention}.
\\\\
Najpopularniejsze sposoby obrony przed SQL Injection to:
\begin{itemize}
  \item Parametryzowane zapytania
  \item Procedury składowane
  \item Filtracja danych wejściowych
\end{itemize} 

W aplikacji zastosowano podejście pierwsze - parametryzowane zapytania(listing
\ref{lst:paramZapyt}).
\\\\
\begin{lstlisting}[caption={Parametryzowane
zapytania},label={lst:paramZapyt}]
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

\end{lstlisting}



\subsubsection{XSS}

 Cross-site-Scripting jest to przede wszystkim atak na klienta
 korzystającego z podatnej aplikacji internetowej(w przeciwieństwie np. do SQL
 injection, którego głównym celem jest część serwerowa). Po drugie, atak polega na wstrzyknięciu do przeglądarki ofiary fragmentu javascript bądź innego języka skryptowego (np. VBScript), który może być uruchomiony w przeglądarce.
 W efekcie, atakujący ma możliwość wykonania dowolnego kodu skryptowego w
 przeglądarce, co posiada poniższe konsekwencje:
 
 \begin{itemize}
   \item Wykradanie cookies - przejęcie sesji ofiary
   \item Dynamiczna podmiana zawartości strony www
   \item Uruchomienie keylogger'a w przeglądarce
 \end{itemize}
 
Ochrona przed XSS polega przede wszystkim na tym, by w odpowiedni sposób
filtrować dane przesyłane przez użytkownika – przed ich wyświetleniem w
aplikacji. Najczęściej przybiera to formę zamiany pewnych istotnych znaków
kontrolnych HTML (głównie znaki otwierające / zamykające tagi
oraz atrybuty tagu) na encje HTML widoczne na Rys.\ref{fig:encje}.

\begin{figure}[ht!]
\begin{center}
\includegraphics[scale=1.0]{encje}
\caption{Zamiana encji}
\label{fig:encje}
\end{center}
\end{figure}

Taka filtracja najprawdopodobniej zlikwiduje większość podatności XSS w
aplikacji.\\\\
 Inną i zazwyczaj niewiele kosztującą metodą ochrony przed jednym z efektów XSS
– tj. wykradaniem cookies – jest zastosowanie parametru HttpOnly dla ciasteczek
sesyjnych\cite{xss}.

\subsubsection{DDoS}

Ataki DDoS wykorzystują dostępną przepustowość serwera, co prowadzi do niedostępności usługi lub infrastruktury.

W trakcie ataku DDoS, na serwer jest przesyłanych wiele zapytań jednocześnie, a
ich ilość może doprowadzić do przerw w dostępie, a nawet do całkowitego braku
połączenia z serwerem.
Istnieją trzy strategie(Tabela \ref{tab:ddosOchrona}), które są wykorzystywane
do zablokowania działania strony internetowej, serwera lub infrastruktury\cite{ddos}.

\begin{table}[ht!]
\caption{Strategie ochrony przed DDoS}
\label{tab:ddosOchrona}
\begin{center}
\begin{tabular}{|p{4cm}|p{12cm}|}
\hline \textbf{ Metoda} &  \textbf{ Opis}\\ \hline \hline
 Przepustowość & Kategoria ataku polegającego na wykorzystaniu zasobów
  sieciowych serwera. Serwer jest niedostępny. \\
\hline
  Zasoby & Kategoria ataku polegającego na wykorzystaniu zasobów
 systemu maszyny i zablokowaniu przekazywania odpowiedzi na poprawne zapytania.
 \\
\hline
  Wykorzystanie błędu w oprogramowaniu & Atak o nazwie ''exploit'',
 który wykorzystuje błąd w oprogramowaniu do zablokowania maszyny lub do przejęcia
  kontroli nad maszyną. \\
\hline
\end{tabular}
\end{center}
\end{table}

Ochrona przed DDoS jest bardzo trudna i często polega na :
\begin{itemize}

  \item Analizowania wszystkich pakietów w czasie rzeczywistym i z dużą
  prędkością
  \item Pobierania ruchu przesyłanego na serwer
  \item Filtrowania czyli identyfikowania niepoprawnych pakietów IP - pozostałe
  pakiety są akceptowane
\end{itemize}
Najlepszym rozwiązaniem dla aplikacji internetowej jest obarczenie
odpowiedzialnością istniejące rozwiązania, np. umieszczenie aplikacji w
chmurze Amazon z usługą Amazon CloudFront oray Amazon Route 53\cite{ddosAmazon}.

\section{Wykorzystane technologie}

W Systemie Rozstrzygania
Konkursów Internetowych wykorzystanych zostało wiele technologii
wykorzystanych w warstwie prezentacji oraz w warstwie serwisu http.\\

\textbf{Dla Warstwy GUI}:
\begin{itemize}
\item Angular
\item Yeoman
\item Grunt
\item Bower
\item HTML/CSS/LESS/jQuery
\item Nodejs
\item Npm
\item Protractor
\item Karma 
  
\end{itemize}

\textbf{Dla serwisu http}:

\begin{itemize}
  \item Spring
\item Hibernate
\item QueryDSL
\item Jackson 
\end{itemize}

\textbf{Dla Bazy danych}:
\begin{itemize}
  \item MySQL 
\end{itemize}



\subsection{Angular}
AngularJS to framework JavaScript stworzony przez inżynierów z Google. Służy on
do szybkiego i~łatwego budowania aplikacji internetowych, tak zwanych – single
app. Model oparty o MVW (Model – View – Whatever) pozwala pogodzić idee JavaScript i modelu MVC.
\subsection{Yeoman}
Yeoman jest ekosystemem generatorów służących tworzeniu szkieletu aplikacji.
\subsection{Grunt}
Grunt jest to system automatyzacji pracy, umożliwia wykonanie określonych
zestawów zadań na danym folderze, czy plikach.
\subsection{Bower}
Bower jest menadżerem paczek klienckich i umożliwia pobieranie zależności. 
\subsection{HTML/CSS/LESS/jQuery}
HTML, CSS oraz jQuery tworzą stronę przeznaczoną do przeglądarki. LESS
służy łatwiejszej generacji arkuszy stylów.
\subsection{Nodejs}
Node.js służy wykonywaniu kodu javascript po stronie serwera.
Node.js to platforma, która zapewnia najwyższą wydajność dzięki wykorzystywaniu
nieblokujących operacji I/O oraz asynchronicznego mechanizmu zdarzeń. Działa na
bazie najwydajniejszego silnika obsługującego język JavaScript – V8 (autorstwa
firmy Google) – i pozwala programistom osiągać niezwykłe efekty\cite{nodejs}.
\subsection{Npm}
Node Packaged Module jest system paczek dla środowiska Node. Dostarcza narzędzia
serwerowe, dotyczące framework'ów.
\subsection{Protractor}
Protractor to narzędzie, które udostępnia pewne mechanizmy służące 
testowaniu aplikacji Angular.js, jednocześnie uruchamiając w tle serwer
Selenium.
\subsection{Karma}
Karma jest narzędziem, które pozwala uruchamiać testy kodu JavaScript pod
różnymi przeglądarkami, a w zasadzie ich emulowanym środowiskiem. Karma nie jest
pełnoprawnym frameworkiem do testowania, a jedynie rusztowaniem, na którego
bazie zbudować można pełny stos testujący JavaScript. Karma zbudowana jest w
oparciu o serwer Node.js oraz technologię Socket.io. Pozwala na wykonywanie
testów w różnych środowiskach pracy (deweloperskim, testowym, produkcyjnym
itd.), a ponadto wykonuje wszystkie testy w separacji od kodu właściwego.
Pozwala także na wykonywanie testów pod różnymi przeglądarkami jednocześnie\cite{karma}.
\subsection{Spring}

Spring to szkielet wytwarzania aplikacji (framework), dzięki któremu proces
budowania oprogramowania w języku Java dla platformy J2EE staje się znacznie
prostszy i efektywniejszy. Spring oferuje usługi, które można z powodzeniem
używać w wielu środowiskach -- od apletów po autonomiczne aplikacje klienckie,
od aplikacji internetowych pracujących w prostych kontenerach serwletów po
złożone systemy korporacyjne pracujące pod kontrolą rozbudowanych serwerów
aplikacji J2EE. Spring pozwala na korzystanie z możliwości programowania
aspektowego, znacznie sprawniejszą obsługę relacyjnych baz danych, błyskawiczne
budowanie graficznych interfejsów użytkownika oraz integrację z~innymi
szkieletami takimi, jak Struts czy JSF\cite{spring}.

\subsection{Hibernate}
Hibernate - framework do realizacji
warstwy dostępu do danych. Hibernate
zwiększa wydajność operacji na bazie
danych dzięki buforowaniu i
minimalizacji liczby przesyłanych
zapytań. Jest to projekt rozwijany jako
open source\cite{hibernate}. 

\subsection{QueryDSL}
QueryDSL to narzędzie do obsługi zapytań SQL, które dostarcza generatory kod i
współpracę z~wieloma bazami, również NoSQL. Zapytania w QueryDSL są
bardziej przyjazne dla użytkownika i~bezpieczne typologicznie.
\subsection{Jackson}
Jackson API zawiera wiele funkcjonalości służące serializacji oraz
deserializacji do formatu JSON.
\subsection{MySQL}
MySQL to wolnodostępny system zarządzania relacyjnymi bazami danych rozwijany
przez firmę Oracle.
